home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000074_jonathan@quake.think.com _Thu Mar 26 18:53:00 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  6KB
  1. Return-Path: <jonathan@quake.think.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA23811; Thu, 26 Mar 92 18:53:00 GMT+0100
  4. Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
  5.     id AA06767; Thu, 26 Mar 92 18:48:28 +0100
  6. Received: from philo.quake.think.com. by quake.think.com (4.1/SMI-4.0)
  7.     id AA00347; Thu, 26 Mar 92 09:48:02 PST
  8. Received: by philo.quake.think.com. (4.1/SMI-4.1)
  9.     id AA00262; Thu, 26 Mar 92 09:47:34 PST
  10. Date: Thu, 26 Mar 92 09:47:34 PST
  11. Message-Id: <9203261747.AA00262@philo.quake.think.com.>
  12. From: Jonny Goldman <jonathan@think.com>
  13. Sender: jonathan@quake.think.com
  14. To: timbl@nxoc01.cern.ch
  15. Cc: www-talk@nxoc01.cern.ch, wais-talk@think.com
  16. In-Reply-To: Tim Berners-Lee's message of Thu, 26 Mar 92 15:25:12 GMT+0100 <9203261425.AA23337@ nxoc01.cern.ch >
  17. Subject: Openning the WAIS document-id syntax
  18.  
  19. First, I'd like to point out the WAIS-FTP doesn't mean a client or server
  20. understands FTP protocol.  It's simply a customized server that functions
  21. like FTP (but is read-only).  It's mainly an experiment in modifying
  22. servers and providing services under WAIS.
  23.  
  24.    Date: Thu, 26 Mar 92 15:25:12 GMT+0100
  25.    From: timbl@nxoc01.cern.ch (Tim Berners-Lee)
  26.  
  27.    [...]
  28.  
  29.    The data model of WAIS (documents in databases) could be deconstrained
  30.    to allow documents themselves to be or contain lists of documents, and
  31.    for lists of documents to point to things other than documents in the
  32.    same database.
  33.  
  34. I take it you're suggesting a new TYPE for a document: Derived types?  In a
  35. sense the catalog is one of these.
  36.  
  37.    This is the way the second part can work.  Normally, a search returns a
  38.    list of doc-ids, each one (basically) like
  39.  
  40.        /usr/local/lib/wais/mydatabase/fred/myfile.txt
  41.  
  42.    which is in fact a filename.
  43.  
  44. Let me also point out that this is just the method used in the sample
  45. server.  The CM server does not return DocID's that are derived from
  46. filenames.
  47.  
  48. In fact, DocID's are "any"s, and that means they can have anything in them,
  49. so long as the server understands how to return a specified amount of data
  50. to a client when presented a DocID and a range.
  51.  
  52.    There's a load of other stuff in there which we can ignore for now.
  53.    What a WAIS search needs to be able to do, when you are pointing to
  54.    files, is to return a pointer to a file in FTP say. We do that in two
  55.    steps.
  56.  
  57. I don't agree.  I think the server should do the retrieval.  The client
  58. should not have to know anything about the REAL location of the document.
  59. More on that below.
  60.  
  61.    First, we recognise that that id is local to the conext of a wais server
  62.    on host myhost and port myport. When the server returns that string, the
  63.    client uses knowledge of the context in which it was quoted to exapnd
  64.    that to
  65.  
  66.        wais://myhost.dom.net:myport/usr/local/lib/wais/mydatabase/fred/myfile.txt
  67.  
  68.    This is a refernece you can quote to anyone as it makes sense anywhere.
  69.    No context.  I called it a UDI but we'll have to change the name.
  70.    Document Access Token maybe.  It's like Brewster's proposal but
  71.    extendable to other protocols.  [Yes, WAIS is a good protocol but there
  72.    are others. Including name servers and directories which will be needed
  73.    for long-lived but movable documents.]
  74.  
  75. This is a good idea, but I feel rather strongly that we should be very
  76. careful in overloading the protocol.  Specifying a syntax for DocID's is
  77. one way of overloading the protocol.  Standardizing types is another.
  78.  
  79.    Now suppose one day a server returns a doc-id INCLUDING the protocol,
  80.    host, etc.  For example, your WAIS FTP engine (like the ARCHIE WAIS)
  81.    returns what are basically pointers to files. Just now, because of the
  82.    constraints of the model, it has to return a part of a file within the
  83.    database. Suppose we change that, so that in your case it just returns a
  84.    doc-id which specifies anonymous ftp access, like:
  85.  
  86. WAIS-FTP doesn't return pointers to remote files.  It returns local DocIDs
  87. for use in retrieving a file local to the server.  Archie WAIS (and
  88. ftpable-readmes) returns these pointers.  That's a different story.
  89.  
  90. Now for a small discussion of WAIS DocID's. So far WAIS DocID's have only a
  91. few fields:
  92.  
  93. typedef struct DocID{
  94.    any* originalServer;
  95.    any* originalDatabase;
  96.    any* originalLocalID;
  97.    any* distributorServer;
  98.    any* distributorDatabase;
  99.    any* distributorLocalID;
  100.    long copyrightDisposition;
  101. } DocID;
  102.  
  103. The part you refer to is just the LocalID part.  If you look at some of the
  104. DocID's returned by the serial server, you'll see the other fields are
  105. filled in (though the Server fields don't contain much useful information -
  106. it's that part we were trying to standardize with the doc-id proposal).
  107.  
  108.        file://otherhost.com/pub/doc/mydoc.txt
  109.  
  110.    The client has a general retrieval engine which can accept doc-ids in
  111.    many domains -- not just WAIS. That allows it to go out over a different
  112.    protocol to retrieve the object.
  113.  
  114. There are two ways to handle this, of course.  Either the client or the
  115. server could do the retrieval.  I believe the server should handle the
  116. protocol part (if the document is stored on some FTP server somewhere, the
  117. WAIS server can just fetch the file, and return it to the client).  This
  118. reduces client complexity.  I have no objection to specifying the
  119. protocol/server in the DocID (perhaps with another field), but we must
  120. standardize the meanings.
  121.  
  122.    This is the way WWW and Gopher work.  They are open systems -- you can
  123.    link into any other system within reason.  That's why the fuss about
  124.    universal document identifiers.  Maybe the WAIS people would to
  125.    incorporate them -- that is, just make sure that the normal WAIS server
  126.    return things which are -- like the one above -- special cases of the
  127.    more general syntax.
  128.  
  129.    I haven't had much comment from the WAIS side about the UDIs, but I'd
  130.    like to have some. (file://info.cern.ch/pub/www/doc/udi1.ps was
  131.    background for the IETF discussions.) We plan a small working group
  132.    hacking out the details before an RFC is submitted.
  133.  
  134. Come up with an RFC, and we'll try to abide by it.  I'd like to caution you
  135. against overloaded strings.  We've got enough of them already.
  136.  
  137. For a start, I'd suggest we use the originalServer as the identifier for
  138. the HOST, and the originalDatabase can inform us of the protocol.
  139.  
  140. - Jonny G